home *** CD-ROM | disk | FTP | other *** search
/ kermit.columbia.edu / kermit.columbia.edu.tar / kermit.columbia.edu / newsgroups / misc.20000114-20000217 / 000048_news@columbia.edu _Mon Jan 17 19:25:56 2000.msg < prev    next >
Internet Message Format  |  2000-02-16  |  5KB
  1. Return-Path: <news@columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id TAA24210
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Mon, 17 Jan 2000 19:25:56 -0500 (EST)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id TAA28343
  7.     for kermit.misc@watsun.cc.columbia.edu; Mon, 17 Jan 2000 19:06:58 -0500 (EST)
  8. X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
  9. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  10. Subject: Case Study #10: Atomic File Movement
  11. Date: 18 Jan 2000 00:06:57 GMT
  12. Organization: Columbia University
  13. Message-ID: <860ar1$rlj$1@newsmaster.cc.columbia.edu>
  14. To: kermit.misc@columbia.edu
  15.  
  16.  
  17. Today let's look at the common situation in which files must be moved from
  18. one computer to another for processing on a regular basis.  For example,
  19. daily business receipts are sent from a branch office or franchise to
  20. company headquarters, or medical or pharmaceutical insurance claims from a
  21. doctor's office, hospital, or pharmacy to a claims clearinghouse.  Each file
  22. contains a series of financial transactions, so we need to ensure that each
  23. transaction occurs once and only once, and when it occurs, it occurs
  24. completely and correctly.  Of course other applications can be imagined too.
  25.  
  26. Let's call the two parties "Branch" and "Headquarters" (HQ).  In a typical
  27. scenario, Branch collects files (e.g. from each operator station) into a
  28. directory and then transmits them every evening to HQ.  The connection can
  29. be made by traditional (non-PPP) dialup or by network.  Of course Kermit is
  30. equally suited to both.  (That's a strong point of Kermit, remember?  For
  31. example, if you normally use a network connection but the net is broken,
  32. you can fall back up old-fashioned dialup using the same script if it is
  33. well-designed.)
  34.  
  35. The procedures for making the connection are well documented in the Kermit
  36. manuals.  Let's assume we have a connection already, we have already
  37. authenticated or logged in, and there is a Kermit server on the far end.
  38. Let's also assume that our current directory on the local computer contains
  39. the files we need to send, and there are many of them.  Of course we can
  40. just tell the local Kermit to "SEND *.*" or whatever, but what happens if
  41. the connection breaks and we have to start again?  We don't want HQ to
  42. receive multiple copies of the same transaction.  (Obviously there should
  43. be other safeguards but we won't discuss them here.)
  44.  
  45. There are several approaches to this problem, but the best one is Kermit's
  46. new "atomic file movement" feature.  In this case "atomic" is used in the
  47. computer-science sense, not the physics one :-)  The command is simple:
  48.  
  49.   SEND /DELETE *.*
  50.  
  51. This means, send all the files whose names match "*.*" (or any other
  52. pattern or filename) and delete each one as soon as, and only if, it was
  53. sent successfully (MOVE is a synonym for SEND /DELETE).  Alternatively, you
  54. can use:
  55.  
  56.   SEND /MOVE-TO:xxxx *.*
  57.  
  58. which, instead of deleting each successfully sent file, moves it to the
  59. directory named xxxx.  (A third choice, SEND /RENAME-TO:, is described
  60. in the update notes.)
  61.  
  62. Now if the connection is lost, you can make a new connection and give the
  63. same SEND /DELETE or SEND /MOVE-TO command again, and it sends only the
  64. files that were not already sent successfully, because the ones that were
  65. are gone.
  66.  
  67. Meanwhile, back at Headquarters we encounter the classic conundrum: how to
  68. know when a file has been completely uploaded?  Let's suppose some process
  69. at HQ (besides Kermit) waits for new files to appear in the upload
  70. directory.  Well, each file "appears" as soon as it is opened, but it might
  71. be open for some time while the Kermit receiver is writing new material to
  72. it (the same is true, of course, for FTP).  We don't want to start
  73. processing it until it has arrived completely, but we also don't want to
  74. wait forever.
  75.  
  76. Here again, atomic file movement is the answer.  If the Kermit server at HQ
  77. is given the command:
  78.  
  79.   SET RECEIVE MOVE-TO xxxx
  80.  
  81. (where xxxx is the name of a directory), this tells it to move each
  82. received file to the specified directory after, and only if, it is received
  83. successfully.  So the script to start up the server at HQ might look like
  84. this:
  85.  
  86.   cd /incoming/tmp/
  87.   set receive move-to /incoming/ready/
  88.   server
  89.   exit
  90.  
  91. The underlying API is chosen to be atomic; for example the UNIX rename()
  92. system call is used (or link() when rename() is not available); the instant
  93. the file appears in the /incoming/ready/ directory, it's ready to use and
  94. not in the middle of being copied.  And it won't come back to haunt you
  95. again after processing, because the Branch won't upload it again.
  96.  
  97. As for making sure the files get through despite repeated disconnections,
  98. see the 'deliver' script on page 453 of "Using C-Kermit" or in the C-Kermit
  99. script library:
  100.  
  101.   ftp://kermit.columbia.edu/kermit/scripts/ckermit/deliver
  102.  
  103. For details about atomic file movement, see Sections 4.0.8, 4.1.3, 4.7 of
  104. the ckermit2.txt file.
  105.  
  106. - Frank